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REMARKS 

The Examiner is thanked for the comments in the Action. They have helped us 
considerably in understanding the Action and in drafting this Response thereto. 

It is our understanding that claims 1-27 remain pending in this application. 
5 We proceed now with reference specifically to the numbered items in the Action. 

Items 1-3 and 7: These are informational in nature and are understood to require no reply. 



Item 4 Response to Arguments: 

10 We thank the Examiner for the initial remark here that the 35 USC 102 (b) rejection is 

withdrawn. We regret that our points on the 35 USC 103(a) rejection where not also persuasive. 
Before turning to the Examiner' s specific remarks on that, however, we think we see now where 
a lot of the confusion in this prosecution has come from. 

Applicant's FIG. 9 is the cover page of this published application, yet it is not particularly 

15 relevant to the present claims. This figure more appropriately goes with the claims in Applicant's 
related application, U.S. Pat. App. no. 10/707,190 (now allowed). Nothing in FIG. 9 represents 
an authentication assertion, where these come from, or how they are used. In contrast, FIG. 15 
shows all of this. Accordingly, we urge that comparing Applicant's FIG. 15 with the figures and 
the text of Andivahis will eliminate a lot of confusion. 

20 Turning now to the content of Item 4 in the Action, the first point of disagreement is 

over authentication assertions. Applicant's position is that the claims recite these and the cited 
references (particularly Andivahis) do not teach or reasonably suggest these, that a prima facie 
case requires that all of the claim limitations appear in the references and therefore that no prima 
facie case for obviousness can be made based on the cited references. The Examiner's position 

25 appears to be that Andivahis teaches something felt to be equivalent to an authentication 

assertion, and that does make a prima facie case for obviousness here. To get past this we need to 
clarify what an authentication assertion actually is, to clarify what Andivahis actually teaches, 
and to determine whether these are the same or at least equivalent. 

The Action here states "Andivahis teaches prior to any action authentication process 

30 takes place between the sender and the key server, the type of authentication information is 
preferably included with each message sent by the sender to the Key Server." OK, but what is 
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missed here is that this information related to authentication is sent by the key server . As we 

discuss in more detail below, Applicant's authentication assertion do not typically come from or 

via a key server — they are used by a key server . To do otherwise presents us with a which came 

first, the chicken or the egg problem. How does Andivahis' key server know it can trust a sender 

5 to be whom they say they are, especially the first time? Applicant's key server (420)(FIG. 15) 

can trust the sources (414) and targets (416) because the authentication assertions (422) they 

provide can be verified, and an authentication assertion is trustworthy because it has been issued 

by an authentication authority (418)(a trusted third party). It follows that Andivahis' 

authentication information is at least not the same as Applicant's authentication assertion, 

10 because the respective elements (assertion/information) come from different sources and are 

used differently. 

Continuing, the Action here states: 

Andivahis teaches registering a user using a personal identifying 
information using additional credentials, such as public key certificate, an ITU 

15 X.509 certificate or the like, the credentials can be used in the future to determine 

which features of the system a user may access. ... Thereafter, the Key Server can 
use the credential information to determine which registered user has requested a 
specific encryption or decryption key, and which services that user has requested. 
... Therefore, Andivahis teaches authenticating a user not only with email address 

20 but also by other credentials such as certificate (i.e. equivalent to the assertion) 

Two things are being missed here. 

First, what Andivahis issues upon registration is not an authentication assertion. 
Semantically, the supply of random bit strings that Andivahis' key server issues are more 
properly termed "receipts." For example, if I take my laundry to ABC Cleaners, it gives me a 

25 receipt; and when my wife takes that receipt back to ABC Cleaners, it gives her back my laundry 
[and if one of us takes that receipt to XYZ Cleaners they laugh at us]. But there is more here than 
semantic games. There is the definition of what an authentication assertion is in Applicant's 
specification. The teachings of Andivahis cannot be reconciled with this and this is why 
Applicant's claims distinguish over the references. For example, in paragraph [0255] the 

30 specification states: 

the authentication authority 418 issues the transacting party 412 an 
authentication assertion 422. ... The assertion 422 includes the identity of the 
transacting party 412; the identity of the authentication authority 418; the validity 
period of the authentication assertion 422; and optional confirmation data, used 
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by the key server 420 to prove that the transacting party 412 is the rightful owner 
of the assertion 422. 

Second, an authentication assertion provides benefits that Andivahis' approach (or any 
combination of the cited references) cannot. Andivahis has to have some mechanism to trust its 
5 senders, and receipts are it. But receipts do not scale up well into real world applications. For 
example again, XYZ Cleaners will not accept a receipt from ABC Cleaners. Under Andivahis, if 
Anna is authenticated with and uses the DEF Key Server and if Bob is authenticated with and 
uses the UVW Key Server, they cannot exchange messages securely until one of them registers 
with the other's key server. In contrast, if the DEF Key Server and the UVW Key Server accept 

10 authentication assertions from National Authentication Server, secure message exchange flows 
smoothly. It follows that Andivahis' authentication information are not equivalent to Applicant's 
authentication assertion. The latter provides additional advantages (ones that none of the 
references or their combination provide). In claim 1 this is a smooth, secure exchange in 
transactions that cannot be repudiated. 

15 Next in Item 4, the Action states: 

Applicant argued that Andivahis is not teaching the use of an 
authentication assertion. Applicant argued that "The cite states the sender is 
authenticated," but the distinction between being authenticated and doing that 
with an authentication assertion has apparently been missed. " Andivahis teaches 
20 a user can register using personal identifying information and using additional 

credentials such as certificate (i.e. equivalent to assertion). 

Respectfully, it looks like the Examiner has confused a perceived functional equivalence 
with structural equivalence. First, the apparent perceived functional equivalence is not truly 
equivalent here. As just discussed above, Applicant's authentication assertions provide 

25 functional advantages over Andivahis' authentication information. But ignoring that temporarily, 
substituting functional equivalence for structural equivalence is wrong. For example, Mr. 
Hindenburg's flying apparatus (function) comprising a balloon full of lighter than air gas 
(structure) did not anticipate or render obvious Mr. Wright's flying apparatus (same function) 
comprising pressure-differential creating wings and ailerons (different structure). 

30 Next in Item 4, the Action states applicant argues "Andivahis does not teach storing 

information from said source authentication assertion, [and] The Examiner would like to point 
out Andivahis teaches registering a user using a personal identifying information using 
additional credentials ... [cite]." Yes, but this is more of what was noted above. What has been 
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missed again is that Andivahis is teaching a key server that is itself working with authentication 
information (performing registration ), not one that is using an existing authentication assertion 
created by an authentication authority. 

Digressing briefly from Item 4 to summarize and conclude with respect to why 
5 Andivahis does not teach or reasonably suggest authentication assertions, we again urge 
considering Applicant's FIG. 15 and the text of claim 1. Applicant is using a trusted third-party 
system. The source (414) and the key server (420) use the authentication authority (418) as a 
trusted third-party. Similarly, the target (416) and the key server (420) use the authentication 
authority (418) as a trusted third-party. Now look at any of Andivahis' figures. There is no 

10 similar trusted third-party. Out of necessity, Andivahis' sender (210) and key server (240) have 
to trust each other, because there is no higher authority to vouch for either. Similarly, Andivahis' 
recipient (220) and key server (240) have to trust each other out of necessity. Of course one can 
argue that Andivahis' sender (210) is party one, its recipient (220) is party two, and its key server 
(240) is its trusted third party. But to the extent this is even functionally equivalent, it only 

15 functions due to Andivahis' use of registration of all parties at its key server (240). As noted 
above and as discussed at length in the Background Art section of Applicant's specification, 
relying on a key server alone has numerous, major disadvantages. As regards structural non- 
equivalence, it should be noted that claim 1 nowhere recites registration. That is because it is 
simply unnecessary if a source or a target has an authentication assertion. In fact, it is a 

20 substantial additional advantage of this invention that a source and/or target can be completely 
anonymous with respect to the key server. 

Continuing again in Item 4, the Action here states "Favazza teaches a customer 
inserting an assertion, and a signature into an initial request to a web service, (page 1, 
paragraphs 9-10)." However, we again urge that Favazza and Andivahis are not properly 

25 combinable. 

More importantly, now that we have both Andivahis and Favazza before us, we 
urge considering something very fundamental that has been overlooked. Applicant's claims 
are all directed to systems and methods to achieve message non-repudiation, and neither 
Andivahis or Favazza teach how to achieve non-repudiation. [Favazza defines the term in 
30 passing along with many general terms in the communications art but, in its application 

providing access to web services, non-repudiation is irrelevant.] This begs the question, if none 
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of the cited references teach non-repudiation, how can any combination of the cited references 
support rejection of Applicant's claims for non-repudiation systems and methods? 

And finally with respect to Item 4, the Action states that Applicant argues "against the 
references individually, one cannot show nonobviousness by attacking references individually 
where the rejections are based on combinations ofreferences. ,, However, the Examiner appears 
to have misunderstood our intent. As previously noted, "the prior art reference (or references 
when combined) must teach or suggest all the claim limitations." MPEP §§ 706.02(j), 2143. 
Applicant's remarks about individual references have been intended to show that the present 
combination of references does not teach or reasonably suggest all of the claim elements. 

Items 5-6 (§ 103(a) rejections): 

These appear to be unchanged from Items 6-7 in the prior Action. Responsive here to, 
Applicant incorporates by reference its remarks in Item 7 of its Response dated 03/08/2007 and 
we respectfully ask reconsideration of those remarks in view of the further remarks above. 

In reviewing the remarks in the last Response, we noted the following typos, and we now 
apologize to the Examiner for any confusion that these have caused. At pg. 5, In. 9 the text "here 
does to support' should have been "here does not support' and at pg. 6, In. 35 the text "the 
Action has filed to" should have been "the Action has failed to." 



Applicant has endeavored to put this case into complete condition for allowance. It is 
thought that the §103 rejections have been completely rebutted. Applicant therefore asks that all 
objections and rejections now be withdrawn and that allowance of all claims presently in the case 
be granted. 



CONCLUSION 



Intellectual Property Law Offices 
1901 S. Bascom Ave., Suite 660 
Campbell, CA 95008 



Respectfully Submitted, 




Telephone: 408.558.9950 
Facsimile: 408.558.9960 



Raymond E. Roberts 
Reg. No.: 38,597 
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